fix: correct the golden_float hash and pin its url to a commit - #4

Follow-up in the same PR. The hash correction alone leaves the fuse armed:

  .url = "https://github.com/gHashTag/zig-golden-float/archive/main.tar.gz"
  .url = "https://github.com/gHashTag/zig-hdc/archive/main.tar.gz"

archive/main.tar.gz is whatever that repository's main happens to be, so
every upstream commit invalidates the pin here and the build breaks on
somebody else's schedule. Both are now pinned to the commits their mains
carry today, e7ce3288 and e3c3e118.

Correcting the claim I made in this PR's first commit: I wrote that
pinning could not be done here because archive/<sha>.tar.gz and
archive/main.tar.gz produce different tarball roots and therefore
different hashes, and that this machine could not compute the new ones. I
measured instead of assuming, and both parts were wrong. Zig hashes the
content tree rather than the archive's root directory name, so the pinned
and unpinned tarballs hash identically. And local Zig 0.16.0 computes the
same hash CI computes on 0.15.2 — verified against the value CI printed,
character for character — so no 0.15.2 toolchain was needed at all.

The other two dependencies in this file, emsdk and raylib-zig, have been
pinned to commits all along. These two were the exceptions, not the
convention.

Dependency resolution now passes here and the error moves one level down,
into zig-hdc, whose own manifest declares the same stale golden_float
hash. Fixed in gHashTag/zig-hdc#4; this build cannot go green until that
lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merging gHashTag/zig-hdc#4 created a new commit there, so the pin added a
moment earlier — e3c3e118 — now points at the version that still declares
the stale golden_float hash. Merging this PR unchanged would have pinned
the broken one and left the build red for a reason that reads like the
fix not working.

Repinned to b73b2fa2 with the hash zig fetch computes for it.

Verified locally: dependency resolution now passes end to end, through
trinity's manifest and into zig-hdc's. The build then stops at
build.zig:88 on `linkLibC`, which Build.Step.Compile does not expose in
Zig 0.16.0 — this machine's version, one ahead of the 0.15.2 the
repository pins. That is a toolchain difference, not a repository defect,
and it is where local verification ends.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Follow-up in the same PR. The hash correction alone leaves the fuse armed:

  .url = "https://github.com/gHashTag/zig-golden-float/archive/main.tar.gz"
  .url = "https://github.com/gHashTag/zig-hdc/archive/main.tar.gz"

archive/main.tar.gz is whatever that repository's main happens to be, so
every upstream commit invalidates the pin here and the build breaks on
somebody else's schedule. Both are now pinned to the commits their mains
carry today, e7ce3288 and e3c3e118.

Correcting the claim I made in this PR's first commit: I wrote that
pinning could not be done here because archive/<sha>.tar.gz and
archive/main.tar.gz produce different tarball roots and therefore
different hashes, and that this machine could not compute the new ones. I
measured instead of assuming, and both parts were wrong. Zig hashes the
content tree rather than the archive's root directory name, so the pinned
and unpinned tarballs hash identically. And local Zig 0.16.0 computes the
same hash CI computes on 0.15.2 — verified against the value CI printed,
character for character — so no 0.15.2 toolchain was needed at all.

The other two dependencies in this file, emsdk and raylib-zig, have been
pinned to commits all along. These two were the exceptions, not the
convention.

Dependency resolution now passes here and the error moves one level down,
into zig-hdc, whose own manifest declares the same stale golden_float
hash. Fixed in gHashTag/zig-hdc#4; this build cannot go green until that
lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merging gHashTag/zig-hdc#4 created a new commit there, so the pin added a
moment earlier — e3c3e118 — now points at the version that still declares
the stale golden_float hash. Merging this PR unchanged would have pinned
the broken one and left the build red for a reason that reads like the
fix not working.

Repinned to b73b2fa2 with the hash zig fetch computes for it.

Verified locally: dependency resolution now passes end to end, through
trinity's manifest and into zig-hdc's. The build then stops at
build.zig:88 on `linkLibC`, which Build.Step.Compile does not expose in
Zig 0.16.0 — this machine's version, one ahead of the 0.15.2 the
repository pins. That is a toolchain difference, not a repository defect,
and it is where local verification ends.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>